Systems and methods for executing real-time reconciliation and notification of electronic transactions

ABSTRACT

Systems and methods of executing a real-time electronic transaction by a real-time transaction system are disclosed. One the method includes receiving, by a reconciliation system, a transaction update associated with a transaction request from a transaction network. The reconciliation system may authenticate the transaction update by communicating with an authentication system. The reconciliation system may translate the transaction update into at least another format. The reconciliation system may transmit the transaction update to a notification handler. The reconciliation system may receive transaction data associated with the transaction update from a transaction query system. The reconciliation system may transmit the transaction update to a transaction requestor associated with the transaction data.

CROSS REFERENCE TO RELATED APPLICATION(S)

This application is a continuation of U.S. application Ser. No.18/055,504, filed on Nov. 15, 2022, which is a continuation of U.S.application Ser. No. 17/337,701, filed on Jun. 3, 2021, the entiretiesof which are incorporated herein by reference.

TECHNICAL FIELD

The present disclosure relates generally to the field of electronictransactions and, more particularly, to systems and methods forexecuting real-time reconciliation and notification of electronictransactions.

BACKGROUND

Businesses, merchants, consumers, financial entities, and/or governmententities may perform electronic fund transfers, payment processing(e.g., e-commerce payments), capital management, etc. domestically andinternationally over various payment networks. However, many aspects ofthe existing electronic payment/fund transaction technology involve someinherent deficiencies or shortcomings that may lead to poor userexperience, increased time and costs, and other inconveniences whensending payments electronically across various payment networks. Forexample, many legacy payment processing networks involve a patchwork ofprocessing systems, fragmented systems, security risks, and the like.The present disclosure is directed to addressing these and otherdrawbacks to the existing electronic transaction systems and services.

The background description provided herein is for the purpose ofgenerally presenting context of the disclosure. Unless otherwiseindicated herein, the materials described in this section are not priorart to the claims in this application and are not admitted to be priorart, or suggestions of the prior art, by inclusion in this section.

SUMMARY OF THE DISCLOSURE

One embodiment provides a method of executing a real-time electronictransaction by a real-time transaction system, the method comprising:receiving, by a reconciliation system, a transaction update associatedwith a transaction request from a transaction network; authenticating,by the reconciliation system, the transaction update by communicatingwith an authentication system; translating, by the reconciliationsystem, the transaction update into at least another format;transmitting, by the reconciliation system, the transaction update to anotification handler; receiving, by the reconciliation system,transaction data associated with the transaction update from atransaction query system; and transmitting, by the reconciliationsystem, the transaction update to a transaction requestor associatedwith the transaction data.

One embodiment provides a real-time transaction system comprising: oneor more computer readable media storing instructions for executing areal-time electronic transaction; and one or more processors configuredto execute the instructions to perform operations comprising: receiving,by a reconciliation system, a transaction update associated with atransaction request from a transaction network; authenticating, by thereconciliation system, the transaction update by communicating with anauthentication system; translating, by the reconciliation system, thetransaction update into at least another format; transmitting, by thereconciliation system, the transaction update to a notification handler;receiving, by the reconciliation system, transaction data associatedwith the transaction update from a transaction query system; andtransmitting, by the reconciliation system, the transaction update to atransaction requestor associated with the transaction data.

One embodiment provides a non-transitory computer-readable mediumstoring instructions for executing a real-time transaction, theinstructions, when executed by one or more processors, causing the oneor more processors to perform operations comprising: receiving, by areconciliation system, a transaction update associated with atransaction request from a transaction network; authenticating, by thereconciliation system, the transaction update by communicating with anauthentication system; translating, by the reconciliation system, thetransaction update into at least another format; transmitting, by thereconciliation system, the transaction update to a notification handler;receiving, by the reconciliation system, transaction data associatedwith the transaction update from a transaction query system; andtransmitting, by the reconciliation system, the transaction update to atransaction requestor associated with the transaction data.

BRIEF DESCRIPTION OF THE DRAWINGS

The accompanying drawings, which are incorporated in and constitute apart of this specification, illustrate several embodiments and togetherwith the description, serve to explain the principles of the disclosure.

FIG. 1 depicts a block diagram of an exemplary electronic transactionsystem, according to one aspect of the present disclosure.

FIG. 2 depicts a block diagram of another exemplary electronictransaction system, according to one aspect of the present disclosure.

FIG. 3 depicts a block diagram of another exemplary electronictransaction system, according to one aspect of the present disclosure.

FIG. 4 depicts a block diagram of another exemplary electronictransaction system, according to one aspect of the present disclosure.

FIG. 5 depicts a block diagram of another exemplary electronictransaction system, according to one aspect of the present disclosure.

FIG. 6 illustrates a flowchart of an exemplary method of executing anelectronic transaction, according to one aspect of the presentdisclosure.

FIG. 7 illustrates a flowchart of another exemplary method of executingan electronic transaction, according to one aspect of the presentdisclosure.

FIG. 8 illustrates an exemplary user interface, according to one aspectof the present disclosure.

FIG. 9 illustrates a flowchart of yet another exemplary method ofexecuting an electronic transaction, according to one aspect of thepresent disclosure.

FIG. 10 illustrates a computer system for executing the techniquesdescribed herein.

DETAILED DESCRIPTION OF EMBODIMENTS

The following embodiments describe systems and methods for facilitatingelectronic transactions. More particularly, the embodiments contemplatedin the present disclosure may enable merchants, customers, businesses,institutions, etc. to utilize a single transaction processor that maycommunicate with transaction requestors and transaction networks inorder to facilitate various electronic transactions.

As discussed above, various aspects of the existing electronic paymenttechnology involve certain drawbacks and deficiencies in executingpayment transactions domestically and/or internationally. For example,the patchwork of complex legacy systems and evolving solutions, the mazeof compliance standards across various markets and payment methods, andarbitrary transaction pricing strategies may lead to slow and unreliabletransactions as well as increased costs and poor user experience.

To address the above-noted problems, the present disclosure describessystems and methods that provide a unified platform that facilitates orprovides, for example: 1) a singular application programming interface(API) to all account-to-account payment methods; 2) managing consistentand globally accepted security and privacy practices; 3) intelligentpayment routing and orchestration capabilities; 4) unifiedreconciliation and reporting across payment methods and schemes; and 5)a single management portal which may provide management of an entirecustomer lifecycle. For example, a transaction processor including anAPI system(s), a security system(s), an analytics system(s), anorchestration system(s), a connection systems(s), and a reconciliationsystem(s) may communicate with a requestor system(s) and transactionnetwork(s) to facilitate and execute electronic transactions of thepresent disclosure.

In one embodiment, the transaction processor of the present disclosuremay receive, via the API system, an electronic transaction request(e.g., an account-to-account fund transfer, purchase payment,reimbursements, etc.) from a user (e.g., a business, merchant, consumer,financial institutions, government institutions, etc.). The API systemmay then transmit the electronic transaction request to thechoreographer system of the transaction processor. The choreographersystem may then transmit the electronic transaction request to at leastone of a routing system, an account ledger system, an auditing system,and/or a transaction system of the transaction processor. The routingsystem may determine an optimal path for executing the electronictransaction in accordance with a routing decision model and the routingconfiguration data. The routing system may then transmit the electronictransaction request to a transaction network via the optimal path. Afterthe routing system transmits the electronic transaction request to thetransaction network, a reconciliation system may receive notifications,messages, and/or acknowledgements from the transaction network. Thereconciliation system may then transmit appropriate messages,notifications, and/or signals associated with the electronic transactionrequest to the user.

In one embodiment, the reconciliation system may receive a transactionupdate (or notification) from the transaction network. Thereconciliation system may then authenticate the transaction update bycommunicating with an authentication system. Additionally, thereconciliation system may translate the transaction update into ageneric format compatible with the transaction processor. Thereconciliation system may then transmit the transaction update to anotification handler. Further, the reconciliation system may receivetransaction data associated with the transaction update from atransaction query system. The reconciliation system may then transmitthe transaction update to the user (or a transaction requestor)associated with the transaction data. Accordingly, one or more users orpayment transaction requestors may keep track of the transactionrequest. That is, the user may be provided with the status of therequested transaction (or payment request) in real-time throughout thetransaction process and until the transaction is complete.

It should be appreciated that particular consideration is made herein topayment transactions relating to businesses, merchants, and/orconsumers. Despite this reference to payment transactions relating tobusinesses, merchants, and or consumers, certain disclosed systems andmethods may apply equally well to various other e-commerce andelectronic transactions. Effectively, any circumstance where credit,currency, crypto currency, collateralized funds, smart contracts, and/ortokenized funds thereto, is being transmitted over a network, systemsand methods disclosed herein may be employed. Further, while the partyseeking to initiate an electronic transaction and/or provide athird-party service may be referred to herein as a business, a merchant,or a consumer, a party seeking to initiate an electronic transactionneed not be a business, a merchant, or a consumer, but may be afinancial institution, a government institution, a service provider, auser, or any party seeking to execute an electronic transaction.

The subject matter of the present disclosure will now be described morefully hereinafter with reference to the accompanying drawings, whichform a part hereof, and which show, by way of illustration, specificexemplary embodiments. An embodiment or implementation described hereinas “exemplary” is not to be construed as preferred or advantageous, forexample, over other embodiments or implementations; rather, it isintended to reflect or indicate that the embodiment(s) is/are “example”embodiment(s). Subject matter may be embodied in a variety of differentforms and, therefore, covered or claimed subject matter is intended tobe construed as not being limited to any exemplary embodiments set forthherein; exemplary embodiments are provided merely to be illustrative.Likewise, a reasonably broad scope for claimed or covered subject matteris intended. Among other things, for example, subject matter may beembodied as methods, devices, components, or systems. Accordingly,embodiments may, for example, take the form of hardware, software,firmware or any combination thereof. The following detailed descriptionis, therefore, not intended to be taken in a limiting sense.

Throughout the specification and claims, terms may have nuanced meaningssuggested or implied in context beyond an explicitly stated meaning.Likewise, the phrase “in one embodiment” or “in some embodiments” asused herein does not necessarily refer to the same embodiment and thephrase “in another embodiment” as used herein does not necessarily referto a different embodiment. It is intended, for example, that claimedsubject matter include combinations of exemplary embodiments in whole orin part.

The terminology used below may be interpreted in its broadest reasonablemanner, even though it is being used in conjunction with a detaileddescription of certain specific examples of the present disclosure.Indeed, certain terms may even be emphasized below; however, anyterminology intended to be interpreted in any restricted manner will beovertly and specifically defined as such in this Detailed Descriptionsection.

Referring now to the appended drawings, FIG. 1 depicts an exemplarysystem 100 including a requestor system(s) 110, a transaction processor120, and a transaction network(s) 140. The requestor system(s) 110, thetransaction processor 120, and the transaction network(s) 140 may be incommunication with each other directly, indirectly, and/or via a network150 (e.g., the Internet and/or one or more cloud networks). Therequestor system(s) 110, the transaction processor 120, and thetransaction network(s) 140 may also be in communication with each otherdirectly via direct lines of communication, via combinations ofphysical, technological, and/or business relationships. The requestorsystem(s) 110 may include one more entities, for example, but notlimited to, treasury, merchants, consumers, businesses, financialinstitutions, government institutions, etc. The requestor system(s) 110may transmit, for example, a request to transmit electronic funds to oneor more receivers.

In one embodiment, the requestor system(s) 110 may be configured tofacilitate a business requesting to transmit electronic funds to aconsumer. In this embodiment, the electronic funds may include, forexample, legal settlements, insurance claims, shareholder dividends,loyalty payments, loans, investment disbursements, customer refundpay-outs, etc. In another embodiment, the requestor system(s) 110 may beconfigured to facilitate a business requesting to transmit electronicfunds to another business. In this embodiment, the electronic funds mayinclude, for example, accounts receivables/payables (AR/AP), rentpayments, business loan payments, payroll, bank-to-bank cross borderpayments, supplier payments, freelancer disbursements, supply chainfinance disbursements, business medical benefits disbursements,affiliate marketing programs disbursements, etc. In another embodiment,the requestor system(s) 110 may be configured to facilitate a consumerrequesting to transmit electronic payments to a business (or amerchant). In this embodiment, the electronic payments may include, forexample, payments at point of sale terminals, payments at eCommercecheckouts, online marketplace payments, online digital content payments,sports wagering payments, telecommunication bill payments, utilitiespayments, rent payments, investment payments, etc. In anotherembodiment, the requestor system(s) 110 may be configured to facilitatea user (e.g., any individual or consumer) requesting to transmitelectronic funds to another user. In this embodiment, the electronicfunds may include, for example, crowdfunding payments, mobile walletpayments, gift payments, person-to-person payments, account-to-accounttransfers, etc. In another embodiment, the requestors system(s) 110 maybe configured to facilitate a government entity requesting to transmitelectronic funds to a consumer. In this embodiment, the electronic fundsmay include, for example, government benefits payments, student aidpayments, tuition payments, tuition reimbursement payments, etc. Inanother, the requestors system(s) 110 may be configured to facilitate auser or consumer requesting to transmit electronic payments to agovernment entity. In this embodiment, the electronic funds may include,for example, transit payments, parking payments, tax payments, permitpayments, payroll payments, etc.

In one embodiment, the requestor system(s) 110 may utilize anintegration portal (or platform) and/or integration services provided bythe transaction processor 120 for integrating user experience and/oruser interfaces (e.g., AR/AP, Enterprise Resource Planning (ERP) system,a website, an app, etc.) for interacting with the transaction processor120. In some embodiments, the requestor system(s) 110 may be integratedwith the transaction processor 120 by using integration toolkits/services and/or a do-it-yourself (DIY) model utilizing the APIsystem(s) 122 of the transaction processor 120.

Still referring to FIG. 1 , the transaction processor 120 may include anapplication programming interface (API) system(s) 122 (e.g., an APIgateway), a security system(s) 124, an analytics system(s) 126, anorchestration system(s) 128, a connection system(s) 130, and areconciliation system(s) 134. The connection system(s) 130 may beconfigured to communicate with various markets domestically and/orinternationally (e.g., Markets 1-N 132 a-132 n). The transactionprocessor 120 may be configured to facilitate electronic transactionsand communications between the requestor system(s) 110 and thetransaction network(s) 140. For example, the API system(s) 122 mayreceive one or more requests to transfer funds (or payments)electronically from the requestor system(s) 110 via an API (e.g., arepresentational sate transfer (RESTful) real-time API or file-basedbatch API) of the transaction processor 120. The RESTful API (or API)may be accessed over one or more public Hypertext Transfer ProtocolSecure (HTTPS) endpoints. The batch API (or API) may be accessed overone or more public Secure File Transfer Protocol (SFTP) endpoints. TheAPI may include capabilities to create customer identities in thetransaction processor 120, associate bank accounts to the customeridentities, and make payments between multiple accounts. The APIsystem(s) 122 may communicate with the security system(s) 124, analyticssystem(s) 126, and the orchestration system(s) 128 to execute theelectronic transactions of the present disclosure. For example, the APIsystem(s) 122 may transmit the electronic fund transfer (or payment)requests to the orchestration system(s) 128. The orchestration system(s)128 may then transmit the electronic payment requests to appropriatenetworks or schemes in the transaction network(s) 140 via the connectionsystem(s) 130. (Further described later in detail below.) Additionally,the reconciliation system(s) 134 may receive notifications, messages,and/or acknowledgements from the transaction network(s) 140, and maytransmit appropriate messages, alerts, and/or signals associated withthe electronic fund transfer request to the requestor system(s) 110 inreal-time.

The transaction processor 120 may be a single processor utilizing asingle API domestically and/or internationally across the globe. Thatis, the transaction processor 120 may facilitate account-to-accountreal-time electronic transactions (e.g., electronic payments, fundstransfer, currency exchange, reimbursement, asset managements, etc.) byestablishing a client centric platform that unifies, orchestrates, andexecutes electronic transactions domestically and/or internationally.Moreover, the transaction processor 120 may be configured to executeelectronic fund transfers, currency exchange transactions, tokenization,and/or electronic transaction authorizations within the single platform.Further, the transaction processor 120 may be configured to operateconsistently, in accordance with globally accepted security and privacypractices. Furthermore, the transaction processor 120 may be configuredto perform intelligent payment routing via the orchestration system(s)128 in real-time based on user (e.g., the requestor system(s) 110)preferences. In some embodiments, the user may make changes totransaction routing preferences (e.g., time and costs of completingpayment transactions) in real-time. The transaction processor 120 of thepresent disclosure may provide, among other things, a single partneraccountability, cost reduction, improved cash flow, increased paymentsecurity, improved access to payments, and better insight andaccountability of payments/funds. Thus, the transaction processor 120may be a one-stop shop for executing payments transactions.

Still referring to FIG. 1 , the transaction network(s) 140 may includeone or more networks or schemes 142 a, 142 b-142 n. The one or moreschemes (or networks) 142 a-142 n may include, for example, an AutomatedClearing House (ACH) networks (e.g., ACH, Same Day ACH, etc.), Cardnetworks (e.g., American Express, Discover, MasterCard, Visa, etc.),Real Time Payment (RTP) networks (e.g., the Clearing House, etc.),blockchain networks, wire transfer networks, Faster Payments network,Bankers' Automated Clearing System (Bacs) Payment Schemes, the ClearingHouse Automated Payment System (CHAPS) network, Single Euro PaymentsArea (SEPA) network, SEPA Instant Credit Transfer (SCT Inst) network,and/or other financial platform networks (e.g., Dwolla, PayPal, WesternUnion, Currencycloud, TransferMate, etc.). The transaction network(s)140 may complete or reject the electronic fund transfer request uponauthenticating and/or authorizing the electronic fund transfer requestin accordance with the established policies and/or rules of one or moreof the schemes 142 a, 142 b-142 n.

FIG. 2 depicts an exemplary system 200 including the transactionprocessor 120. Specifically, the portion depicted in FIG. 2 represents amore detailed example illustration of the transaction processor 120, butwhich should not be construed as limiting transaction processor 120. Thetransaction processor 120 may include one or more of the API system(s)122, the security system(s) 124, the analytics system(s) 126, theorchestrating system(s) 128, a management portal system(s) 218, anauditing system(s) 220, a notification system(s) 222, and a tokenizationsystem(s) 224. The API system(s) 122 may facilitate communications withthe requestor system(s) 110, transaction network(s) 140, and between oneor more systems (or microservices) of the transaction processor 120depicted in FIG. 2 . For example, the API system(s) 122 may utilize APIs(e.g., internal or external APIs), batch APIs, and/or notification APIsin order to facilitate the execution of the electronic transactions ofthe present disclosure. In one embodiment, the RESTful API of the APIsystem(s) 122 may be accessed over one or more public Hypertext TransferProtocol Secure (HTTPS) endpoints. The API system(s) 122 may utilize,for example, POST, GET, and PUT methods to execute and facilitate theelectronic transactions of the present disclosure. In anotherembodiment, the batch API of the API system(s) may be accessed over oneor more public Secure File Transfer Protocol (SFTP) endpoints.

Still referring to FIG. 2 , the security system(s) 124 may facilitate,for example, user (or customer) access control, user throttling, and/oruser identification. In one embodiment, the security system(s) 124 mayensure that the transaction processor 120 is in compliance with one ormore data protection standards. One or more data elements of thetransaction processor 120 may be monitored in order to meet the one ormore encryption standards established by the transaction processor 120.For example, data elements, such as, personally identifiable information(PII), payment card data (PCI data), authentication credentials, othersensitive data, company confidential data, etc. may be monitored by thesecurity system(s) 124.

In one embodiment, the security system(s) 124 may facilitate and managethe encryption of data and/or keys associated with the electronictransactions of the present disclosure. For example, the securitysystem(s) 124 may include a key management service (KMS) that mayestablish a time-limit for the life of an encryption key. The KMS may bemanaged internally or externally (e.g., Amazon Web Service KeyManagement Service (AWS KMS)) from the transaction processor 120. In oneembodiment, once an encryption key exceeds its lifespan, the encryptionkey may be deleted from an encryption key cache in the transactionprocessor 120. The encryption key may then be replaced with a newlygenerated key by the KMS. This functionality may provide compliance witha data key rotation policy that may be established by the transactionprocessor 120, for example, by setting a cache expiration that is withinthe data key rotation policy limits. Further, access to the keys in theKMS may be limited by the access control of the security system(s) 124and may be assigned with least-privilege.

In one embodiment, the security system(s) 124 may be configured to giveaccess to users to call operations against KMS Customer Master Key (CMK)with only the designated service and/or user identities. The securitysystem(s) 124 may also audit the use and access of the master keys.Further, the security system(s) 124 may utilize a secure hash function(e.g., Secure Hash Algorithm-256 (SHA-256)) for data elements that areencrypted but also must be searched on. Since there may be cases wherethe hashed data elements (e.g., Sender name, Sender account number,Sender routing number, Receiver Name, Receiver account number, Receiverrouting number, etc.) may be searched across all tenants, hashed dataelements may have a global salt. In one embodiment, sensitive dataelements that are at rest may be stored in the transaction processor 120using Advanced Encryption Standard (AES)-256. Also, any message data inmotion may be protected by enforcing a minimum of Transport LayerSecurity (TLS) 1.2.

Still referring to FIG. 2 , the analytics system(s) 126 may comprise adata storage (e.g., a data lake) and a data platform for performinganalytics. For example, the auditing system(s) 220 and the managementportal system(s) 218 may be in communication with the analyticssystem(s) 126 in order to perform analysis and auditing on theelectronic transactions of the present disclosure. The auditingsystem(s) 220 may subscribe to transaction event topics and transmit theevent topics to a data lake for analytics. The management portalsystem(s) 218 may facilitate onboarding, configuration, andcertification for the users of the transaction processor 120. Themanagement portal system(s) 218 may provide self-service functionalityfor the users of the transaction processor 120 as well as administrativefunctionality for the internal support teams of the transactionprocessor 120.

Still referring to FIG. 2 , the orchestration system 128 may include achoreographer system(s) 210, a portal system(s) 212, a routing system(s)214, and transaction system(s) 216. The choreographer system(s) 210 maybe configured to choreograph the steps required to process one or morereal-time electronic transaction requests or one or more real-timetransaction inquiries of the present disclosure. For example, thechoreographer system(s) 210 may be configured to verify whether atransaction requestor (e.g., requestor system(s) 110) has permission torequest transactions and/or inquiries. For example, the choreographersystem(s) 210 may make an internal API call to an authorization systemof the transaction processor 120.

In one embodiment, the choreographer system(s) 210 may facilitateexecution of electronic funds transfer requests (or payment requests).For example, the choreographer system(s) 210 may make an internal APIcall to an account validation query system of the transaction processor120 to validate whether the source account exists. The accountvalidation query system may verify the formatting of the source anddestination account. Further, the choreographer system(s) 210 may beconfigured to make internal API calls to an authorization system of thetransaction processor 120 to verify that the user has permissions toperform payment using the specified source account. In one embodiment,the choreographer system(s) 210 may be configured to post a paymentrequest to event-topic stream (e.g., Kafka) transactions. Thechoreographer system(s) 210 may be configured to respond back to anexternal API caller that the payment request has been accepted forprocessing.

In one embodiment, the choreographer system(s) 210 may be configured toprocess transaction inquiries in real-time. For example, thechoreographer system(s) 210 may make internal API calls to thetransaction query system to perform transaction lookups. Further, thechoreographer system(s) 210 may make internal API calls to theauthorization system to verify whether the user has permissions to viewthe transaction and associated accounts. Additionally, the choreographersystem(s) 210 may respond back to an external API call through the APIsystem(s) 122 with the inquiry response.

Still referring to FIG. 2 , the portal system(s) 212 may be configuredto facilitate, for example, subscription management of users (orcustomers) or developers, tier and feature configurations, customeradministration, funding source managements, etc. The portal system(s)212 may allow the developers or users of the requestor system(s) 110 toinitiate transactions or payment requests, transmit transaction status,receive notifications, etc. in real-time. The portal system(s) 212 maybe configured to facilitate or provide an integration portal that mayinclude, for example, a unified developer portal (e.g., sandboxinterface) that the developers may utilize in order to integrate therequestor system(s) 110 with the transaction processor 120. Theintegration portal may enable the developers to configure the requestsystem(s) 110 to access, communicate with, and utilize thefunctionalities of the transaction processor 120. In some embodiments,the integration portal may include an interactive marketing platform ofthe transaction processor 120. The marketing platform may provide, forexample, demonstration sections of how payments happen and what happensin the backend of the transaction processor, as well as various usecases for accessing, communicating with, and utilizing thefunctionalities of the transaction processor 120. Thus, the integrationportal may achieve seamless integration of the requestor system(s) 110with the transaction processor 120 via the marketing portal and theintegration portal.

In one embodiment, the integration portal may include live connectionsto the APIs of the transaction processor 120, code snippets forcommunicating with the transaction processor 120, and a certificationinterface for certifying the APIs used for communicating with thetransaction processor 120. The code snippets may be provided indifferent languages and in real-time. For example, changing the RTPscheme to a different scheme may be achieved by editing the snippets ina live sandbox environment. Further, the integration portal may provideUniform Resource Locator (URL) links to the developers to allow using acommon API by following the provided links and integrating with thetransaction processor 120 easily and intuitively without having to storeany separate URLs. Furthermore, the transactions may be updated inreal-time via the integration portal. For example, payment rails may bechanged based on the due date, the ability to cancel payments, etc.Additionally, the integration portal may provide notifications regardingthe transaction that the users can access and see without having toemail or call.

Still referring to FIG. 2 , the routing system(s) 214 may facilitateroute deciding, fastest routing, least cost routing, market schemeconfiguration, market routing configuration, multi-geo routing, etc. Therouting system(s) 214 may execute transaction routing by looking at bothcustomer configuration and scheme capabilities. The data associated withprice, speed, and capability across both the customer and schemes may beutilized to identify the best possible route for the electronictransactions depending upon configuration for a specific customer andwhether the customer has a speed versus cost processing preference. Therouting system(s) 214 may utilize an open-source business rulemanagement system (BRMS) (e.g., Drools) to implement the routingdecision models. The routing system(s) 214 may be configured tofacilitate and choreograph the steps required to route and executepayment requests. The routing system(s) 214 may subscribe to transactionevent topics and may act on payment initiated events to initiate routingrequests. In one embodiment, the routing system(s) 214 may make internalAPI calls to an entitlement query system(s) to retrieve customerspecific configuration details that may impact the route of the paymentrequests. The routing system(s) 214 may process transaction requests,including customer entitlement details, through a routing model toidentify the appropriate payment scheme adapter (further described inmore detail below). The routing system(s) 214 may make internal APIcalls to one or more payment scheme adapters, which then may call themarket specific payment scheme implementation. Further, the routingsystem(s) 214 may publish route chosen events to a transaction eventtopic data steam.

Still referring to FIG. 2 , the transaction system(s) 216 may beconfigured to facilitate, for example, electronic funds transferrequests, electronic funds transfer information request, electronicfunds transfer advice, electronic funds transfer authorization,acknowledgement, reversal, modification, and refund, etc. Thetransaction system(s) 216 may be in communication with the notificationor messaging system(s) 222. The notification system(s) 222 may receivenotifications from the payment schemes (e.g., schemes 142 a-142 n) toprovide status updates as a transaction moves thorough its lifecycle.The notifications from the payment schemes, along with the associatedscheme details, may be received through the API system(s) 122. Thenotification system(s) 222 may respond to the notifications withacknowledgments. The notification system(s) 222 may then publish apayment notification received event to a payment notification topic. Inone embodiment, the notification system(s) 222 may include a paymentnotification handler that subscribes to payment notification topics andawait the payment notification received messages. That is, when an eventis processed, the payment notification handler may first make aninternal API call to a transaction query system(s) to retrieveadditional details of the transaction associated with the paymentnotification. The payment notification handler may then publish to apayment notification topic, a payment acknowledgement message.

The connection system(s) 130 may include one or more adapters forcommunicating with the transaction network(s) 140. For example, theconnection adapters for Market 1 132 a may include a TCH RTP adapter,ACH adapter, account to card adapter, wire adapter, payment adapter,account to wallet adapter, clearing/settlement adapter, etc.Additionally or alternatively, the connection adapters for Market N 132n may similarly include, for example, ACH adapter, wire adapter, schemeadapter, wire adapter, paynet adapter, account to wallet adapter,clearing/settlement adapter, etc.

In one embodiment, the transaction system(s) 216 may receive informationassociated with the electronic transactions of the present disclosureand facilitate the execution of the electronic transactions. Thetransaction system(s) 216 may transmit the transaction information tothe tokenization system(s) 224. The tokenization system(s) 224 may thengenerate tokens to use surrogate values for the sensitive accountdetails used for payment transactions requested by the requestorsystem(s) 110. A token may be a low-value token or a high-value token.Further, a token may be a randomly generated number. In otherembodiments, a token may be a pseudorandom number, encryptedinformation, or other character sequence.

The transaction processor 120 may be deployed to servers and datacenters in multiple regions and availability zones. The transactionprocessor 120 may be cloud-native and cloud-agnostic utilizingcontainerized microservices and may be deployed to an elasticinfrastructure on an open-source container-orchestration systemKubernetes). In one embodiment, the transaction processor 120 may bedeployed and built completely in cloud. Thus, the complexity of thetransaction processor 120 may be contained by building ground-up withcloud-based microservices design (e.g., AWS Cloud infrastructure). Thecloud-based microservices design of the present disclosure may allowquick enhancements and elastically scaling the transaction processor 120without customer impact or downtime. For example, small teams ofdevelopers may quickly add enhancements and new scheme supports. Also,failures may be contained and may prevent collateral damage to otherfunctionality.

FIG. 3 depicts an exemplary system 300 for facilitating an electronictransaction request (e.g., a payment request) of the present disclosure.The system 300 may include, for example, the requestor system(s) 110,the transaction processor 120, the transaction network(s) 140, and thereceiver system(s) 310. In this embodiment, the transaction processor120 may include, further to the systems depicted in FIG. 3 , one or moresystems or microservices. For example, the transaction processor 120 mayinclude an authorization system(s) 302, an account validation system(s)304, an account ledger system(s) 306, and an auditing system(s) 220,which may be in in communication with the choreographer system(s) 210.In this embodiment, the connection system(s) 130 may include one or morescheme or network adapters. For example, the connections system(s) 130may include an RTP adapter 312 a, an ACH adapter 312 b, a wire adapter312 n, etc. Further, the connection system(s) 130 may include connectors314 a-n that may be configured to facilitate communication with thetransaction network(s) 140.

Still referring to FIG. 3 , the authorization system(s) 302 may exposean internal API that may be called by other systems or microserviceswithin the transaction processor 120 to verify that a user has access toperform operations and view data. The account validation system(s) 304may exposes an internal API that may be called by other systems ormicroservices within the transaction processor 120 to perform inquiriesagainst account details stored in a transaction processor database (notshown in the figure). The account ledger system(s) 306 may expose aninternal API that may be called by other systems or microservices withinthe transaction processor 120 to perform inquiries against accountledger details stored in the database of the transaction processor 120.The account ledger system(s) 306 may subscribe to the transaction eventtopics of Kafka streams transmitted by the choreographer system(s) 210in accordance with the present disclosure. Further, the account ledgersystem(s) 306 may watch for complete states and may use these events toupdate the ledger database. In one embodiment, the auditing system(s)220 may subscribe to the transaction event topics of Kafka streamstransmitted by the choreographer system(s) 210. The auditing system(s)220 may transmit these events to a data lake for analytics.

Still referring to FIG. 3 , the transaction system(s) 216 may expose aninternal API that may be called by other systems or microservices withinthe transaction processor 120 to perform inquiries against accountdetails stored in a Not Only Structured Query Language (NoSQL) databaseprovided by the transaction processor 120. As described in reference toFIG. 2 , the routing system(s) 214 may be responsible for choreographingthe steps required to route and execute payment requests. The routingsystem(s) 214 may subscribe to the transaction event topics of Kafkastreams transmitted by the choreographer system(s) 210 and may act onpayment initiated events to initiate routing requests. The routingsystem(s) 214 may make an internal API call to the Entitlement QueryService to retrieve customer specific configuration details that mayimpact the route. The routing system(s) 214 may process the request,including the customer entitlement details, through the routing model toidentify the appropriate payment scheme adapter.

Still referring to FIG. 3 , the RTP adapter 312 a may expose an internalAPI for processing payments across RTP schemes or rails. The RTP schemeadapter 312 a may call into the internal/external market specific APIRTP rail implementation. The ACH adapter may expose an internal API forprocessing payments across ACH rails. The ACH adapter 312 b may callinto the internal/external market specific API ACH rail implementation.The wire adapter 312 n may expose an internal API for processingpayments across wire rails. The wire adapter 312 n may call into theinternal/external market specific API wire rail implementation.

In one embodiment, incoming payment requests (e.g., a payment requestAPI) from users (e.g., a payment sender) in the requestor system(s) 110may be managed by the API system(s) 122. The API system(s) 122 mayexecute an authentication check of the user identify (e.g., via an OpenAuthorization 2.0 (OAuth2)) by communicating with an identity provider(IdP) of the transaction processor 120. The API system(s) 122 may thenforward the payment request to the payment choreograph system(s) 210.The choreographer system(s) 210 may then initiate an authorization checkwith the authorization system(s) 302. Once authorization system(s) 302verifies the requestor system(s) 110 has permission to perform thetransaction, the choreographer system(s) 210 may communicate with theaccount validation system(s) 304 to check whether the user in requestorsystem(s) 110 exist in a database of the transaction processor 120. Thechoreographer system(s) 210 may then stream Kafka messages that may bereceived by the account ledger system(s) 306, auditing system(s) 220,transaction system(s) 216, and the routing system(s) 214.

Still referring to FIG. 3 , the routing system(s) 214 may forward thepayment request to the optimal scheme (or rail) adapter in theconnection system(s) 130. The connection system(s) 130 may then transmitthe payment request to the appropriate scheme (e.g., schemes 142 a-142n) in the transaction network(s) 140. In one embodiment, a third-partyservice provider may directly implement one or more adapters provided bythe connection system(s) 130. Thus, the transaction processor 120 maynot be required to integrate to the third-party service provider API.

FIG. 4 depicts an exemplary system 400 for facilitating transactionreconciliation and notification of the present disclosure. The system400 may include, for example, the requestor system(s) 110, thetransaction processor 120, the transaction network(s) 140, and areceiver system(s) 310. In this embodiment, the transaction processor120 may include, further to the systems depicted in FIGS. 3 and 4 , anauthentication system(s) 401, a file transfer system(s) 402, a schemenotification system(s) 404, a payment notification handler 406, and atransaction query system(s) 408. In one embodiment, the reconciliationsystem(s) 134 may include the scheme notification system(s) and thepayment notification handler 406. Of course, other systems of thetransaction processor 120 shown in FIG. 4 may be integrated into thereconciliation system(s) 134 to execute the reconciliation andnotification process of the present disclosure. In one embodiment, theauthentication system(s) 401 may authenticate APIs using an OAuth2protocol against an identity provider (IdP) of the transaction processor120. Further, the authentication system(s) 401 may authenticate usernameand password for accessing the portal system(s) 212. In one embodiment,the scheme notification system(s) 404 may translate scheme specificnotifications into a generic non-scheme specific format. The filetransfer system(s) 402 may aggregate the notifications received from theschemes 142 a-142 n into a file and send to the receiver system(s) 310based on the configured preferences. The transaction query system(s) 408may expose an internal API that may be called by other systems ormicroservices of the transaction processor 120 to perform inquiriesagainst account details stored in the NoSQL database. Further, thetransaction query system(s) 408 may subscribe to transaction eventtopics from the Kafka streams of the transaction processor 120 and mayutilize these events to update the NoSQL database. In one embodiment,the payment notification handler 406 may subscribe to paymentnotification topics and await the payment notification receivedmessages. That is, when an event is processed, the payment notificationhandler 406 may first make an internal API call to a transaction querysystem(s) 408 to retrieve additional details of the transactionassociated with the payment notification. The payment notificationhandler 406 may then publish to a payment notification topic, a paymentacknowledgement message.

In one embodiment, the schemes 142 a-142 n in the transaction network(s)140 may provide transaction updates to the transaction processor 120 asa transaction is processed. The updates may be received by the APIsystem(s) 122 or as batch files (Secure File Transfer Protocol (SFTP)push or pulls) handled by the file transfer system(s) 402. The updatesmay also be authenticated by the authentication system(s) 401 tovalidate the sender of the updates. Upon successful validation, theupdates may then be routed to the scheme notification system(s) 404. Thescheme notification system(s) 404 may translate the scheme specificnotification into a generic non-scheme specific format. The genericmessage may be pushed onto the Kafka message que and may be received bythe payment notification handler 406. The payment notification handler406 may call the transaction query system(s) 408 to retrieve thetransaction details from a database of the transaction processor 120.The payment notification handler 406 may then transmit a Kafka messageto the account ledger system(s) 306, auditing system(s) 220, and thetransaction system(s) 216, and/or the file transfer system(s) 402. Thefile transfer system(s) 402 may aggregate the notifications into a file.The notification file may then be sent to the receiver system(s) 310based on the configured preferences (e.g., a Webhook to the configuredHTTPs endpoint, an SFTP push to the configured SFTP endpoint, and/or anSFTP pull form the receiver system(s) 310 to an SFTP server of thetransaction processor. Thus, the reconciliation and notification aspectsof the present disclosure may provide a real-time status of the paymentto the requestors system(s) 110, allowing the transaction requestors toalways know where the payment stands.

FIG. 5 depicts an exemplary system 500 for facilitating a transactionrouting of the present disclosure. The system 500 may include, therouting system(s) 214, a fraud monitoring system(s) 530, and a machinelearning system(s) 532. In this embodiment, the routing system(s) 214may include a routing decision model(s) 502. In one embodiment, therouting system(s) 214 may perform transaction routing by looking at bothcustomer configurations and scheme capabilities. That is, the routingsystem(s) 214 may consider price, speed, and capability facts acrossboth the customers and the schemes (e.g., schemes 142 a-142 n) and mayidentify the best possible route for the transaction. The route for thetransaction may be determined based on the configurations or preferencesof a customer (e.g., speed versus cost processing preference). In oneembodiment, the routing decision model(s) 502 may utilize at least thefollowing data to determine an optimal path for executing the electronictransactions (e.g., payment request) of the present disclosure: currentdate 504, transaction amount 506, desired transaction date 508, schemeexecution dates 510, scheme decisions 512, scheme holidays 520, schemeprocessing time 522, scheme costs 524, scheme amount limits 526, andcustomer preferences 528. The optimal path for executing, for example, apayment request, may be based on the user's (or client's) desiredpreferences. In one embodiment, the routing decision model(s) 502 mayconsider, for example, two key inputs: transaction amount 506 anddesired transaction date 508. That is, the routing decision model(s) 502may factor in customer preferences and business knowledge to makedecisions on the transaction schemes 142 a-142 n and scheme executiondates 510.

In one embodiment, one or more routing criteria may be considered by therouting decision model(s) 502 to determine the optimal transactionroutes. For example, with respect to geography, the following questions,for example, may be considered: 1) Is this a U.S. domestic transaction?2) Is this a U.K. domestic transaction? 3) Is this cross-border? and soon. Each option may affect or change the available routes and influencethe decisioning processes of the routing decision model(s) 502.Regarding the scheme holidays 520 and the scheme processing time 522,unlike the RTP scheme, for example, other schemes or rails may take daysto process a transaction. In order ensure that a transaction getsprocessed on time, the processing time must be calculated and trace backto ensure any non-processing windows like a weekend or a bank holidayare not ignored. Regarding the scheme (or rail) costs 524, the costs mayvary from rail to rail. As such, depending on the customer preference,the transactions may be routed through the cheapest rout. Regarding thescheme amount limits 526, a transaction may exceed a particular rail'smaximum allowed threshold. In such a case, the routing decision model(s)502 may not consider that particular route option or potentially split atransaction across multiple payment rails. The rules built by therouting decision model(s) 502 may be configurable, for example, atdifferent hierarchies: global system-wide rules; rules particular to apayment scheme; and customized client specific rules. Beyond therules-based routing inputs, the routing system(s) 214 may take real-timefeedback from the fraud monitoring system(s) 530. That is, based on afraud profiling conducted by the fraud monitoring system(s) 530, atransaction may be to a different rail. For example, a risky transactionmay be moved from an RTP scheme to a credit scheme if the credit schememay allow for charge-backs. Also, inputs from the machine learningsystem(s) 532 (e.g., Ethos) may provide out-of-band, non-real-timemachine learning feedback to adjust payment routes as subtle trends areidentified.

FIG. 6 illustrates a flowchart of an exemplary method 600 of executingan electronic transaction of the present disclosure. Exemplary processflows of the method 600, performed in accordance with the systems 100,200, and 300 above, are described hereinafter.

At step 610, the API system(s) 122 may receive a payment request from auser (e.g., requestor system(s) 110). At step 612, the API system(s) 122may communicate with the authentication system(s) 302 to authenticatethe user. The authentication system(s) 302 may communicate with anidentity provider (IdP) of the transaction processor 120 to verify theauthenticity of the identity of the user. At step 614, the API system(s)122 may transmit the payment request to the choreographer system(s) 210.At step 616, the choreographer system(s) 210 may make an internal APIcall to an authorization system(s) 601 of the transaction processor. Theauthorization system(s) 601 may verify whether the user has permissionsto perform a payment request. The authorization system(s) 601 may thentransmit an authorization response to the choreographer system(s) 210.At step 618, the choreographer system(s) 210 may make an internal APIcall to an account validation system(s) 602 to verify whether thereferenced bank accounts associated with the payment request exists inthe transaction processor 120. At step 620, the account validationsystem(s) 602 may communicate with an account query system(s) 604 of thetransaction processor 120 to confirm whether the bank accountsassociated with the payment request exists outside of the transactionprocessor 120. At step 622, the account validation system(s) 602 maytransmit a validation response message to the choreographer system(s)210. At step 624, the choreographer system(s) 210 may make an internalAPI call to the authorization system(s) 601 to verify that the user haspermission to transact against the sender account. The authorizationsystem(s) 601 may then transmit an authorization response to thechoreographer system(s) 210. At step 626, the choreographer system(s)210 may publish, via an event-topic stream (e.g., Kafka stream) apayment request message to the account ledger system(s) 306, theauditing system(s) 220, and the transaction system(s) 216. Thechoreographer system(s) 210 may also respond back to the user that thepayment request has been accepted for processing. Further, the paymentrequest message may be sent to its subscribers for processing. Forexample, the routing system(s) 214 may receive the payment request eventand may begin processing the payment. The transaction query system mayreceive the payment request event and update its NoSQL database. Theaccount ledger system(s) 306 may receive the payment request event andmay ignore it since they payment has not yet been completed. At step628, the auditing system(s) 220 may transmit the payment request eventto the database system(s) 604 for analytics.

FIG. 7 illustrates a flowchart of an exemplary method 700 of executingreal-time reconciliation and notification of an electronic transactionin accordance with the present disclosure. Example process flows of themethod 700, performed in accordance with the systems 100, 200, 300, 400,and 500 above, are described hereinafter.

At step 710, the API system(s) 122 may receive, from the transactionnetwork(s) 140, a transaction notification (or update) messageassociated with the payment request made by the user in accordance withthe process 600 of FIG. 6 . The notification message may include one ormore real-time statuses of the payment request(s) received by thetransaction network(s) 140. For example, one of more transaction schemesof the transaction network(s) 140 may generate, in real-time, alerts,messages, notification, and/or signals when a new event (e.g., failedtransaction, rejected transaction, pending transaction, settledtransaction, etc.) associated with a payment request is detected orcreated by the one or more transaction schemes. In one embodiment, thenotification message may include one or more scheme-specific formats.The notification message may be received by the file transfer system 402via SFTP push/pull protocol messages. At step 712, the API system(s) 122and/or the file transfer system 402 may request to authenticate thenotification message received from the transaction network(s) 140 byutilizing, for example, an OAuth2 protocol or SFTP push/pull protocolmessages.

Still referring to FIG. 7 , at step 714, the authentication system(s)302 may generate and transmit an authentication response to the APIsystem(s) 122 and/or the file transfer system 402. The authenticationresponse may be generated based on the information associated with thetransaction request, the requestor system(s) 110 that transmitted thetransaction request, the transaction request receiver, etc. At step 716,the API system(s) 122 and/or the file transfer system 402 may transmitone or more API calls including the authenticated notification messageto one or more matching scheme notification system(s) 404 of thereconciliation system 134. In one embodiment, the scheme notificationsystem(s) 404 may translate the scheme specific notification messageinto a non-scheme specific format that may be compatible for processingand communicating by the transaction processor 120. At step 718, thescheme notification system(s) 404 may transmit, for example, via a Kafkastream, a payment notification topic stream 702 to the paymentnotification handler 406. At step 722, the payment notification handler406 may transmit a transaction detail request to the transaction querysystem(s) 408 to retrieve the transaction details (e.g., payment sender,receiver, transaction preference, etc.) associated with the paymentrequest made by user of the requestor system(s) 110.

At step 724, the transaction query system(s) 408 may transmit thetransaction details associated with the payment request of the user. Atstep 726, the payment notification handler 406 may generate a statusmessage in accordance with the transaction details and the notificationmessage received from the scheme notification system(s) 404. The paymentnotification handler 406 may then transmit the status message via anevent-topic stream 704, for example, via a Kafka message, to one or moremicroservices (e.g., account ledger, auditing system(s) transactionstore, etc.) of the transaction processor 120 for further processing. Inone embodiment, the message transmitted via the event-topic stream 704may be utilized by the transaction processor 120 to generate one or moreuser interfaces. For example, the transaction processor 120 may generatea transaction activity interface 802 shown in FIG. 8 . The transactionactivity interface 802 may include information associated with thestatuses of the transactions requested by the requestor system(s) 110.In one embodiment, the users of the requestor system(s) 110 may accessthe transaction activity interface 802 to obtain real-time statuses oftransaction requests made via the requestor system(s) 110. For example,a user of the requestor system(s) 110 may obtain information associatedwith transactions, rejected transactions, pending transactions, settledtransactions, etc. In some embodiments, the user may request to alter ormake changes to transaction request via the transaction activityinterface 802.

Still referring to FIG. 7 , at step 728, the payment notificationhandler 406 may transmit the notification message to the requestorsystem(s) 110 based on one or more configuration preferences of therequestors system(s) 110. For example, the notification message may besent to the requestor system(s) 110 via: a webhook to a configured HTTPsendpoint; an SFTP push to a configured SFTP endpoint of the requestorsystem(s) 110, and/or an SFTP pull from one or more users (or clients)to an SFTP server of the transaction processor 120. Accordingly, one ormore users or the requestors system(s) 110 may keep track of the requesttransactions. For example, the users or the requestor system(s) 110 maybe notified of the status of a transaction (or payment request) inreal-time. Accordingly, the notifications or updates generated andtransmitted by the reconciliation system(s) 134 may provide real-time,up-to-date information regarding the transaction requests of the presentdisclosure. Additionally, the users or the requestor system(s) 110 mayutilize the reconciliation system(s) 134 of the present disclosure toprovide independent systems (e.g., an Enterprise Resource Planning (ERP)systems) to stay up-to-date in real-time on the statuses of thetransaction requests of the present disclosure. Further, the users orthe requestor system(s) 110 may register a (Uniform Resource Locator)URL to receive real-time notification on the statuses of the transactionrequests.

FIG. 9 illustrates a flowchart of another exemplary method 900 forexecuting reconciliation and notification of an electronic transactionin accordance with the present disclosure. Example process flow of themethod 900, performed in accordance with the systems 100, 200, 300, 400,and 500 above, are described hereinafter.

At step 902, a reconciliation system (e.g., reconciliation system(s)134) may receive a transaction update (or a notification message) from atransaction network. In one embodiment, the transaction updateassociated with the transaction request may be received in real-timewhen the transaction network generates one or more updates associatedwith the transaction request. Further, the reconciliation system mayreceive the transaction update via an Application Programing Interface(API) call and/or a Secure File Transfer Protocol (SFTP) message. In oneembodiment, the transaction update may be associated with one or morepayment requests by a requestor system (e.g., requestor system(s) 110).At step 904, the reconciliation system may authenticate, the transactionupdate by communicating with an authentication system (e.g.,authentication system(s) 302). In one embodiment, the reconciliationsystem may route the transaction update to a matching transactionnetwork notification system (e.g., the scheme notification system(s)404).

At step 906, the reconciliation system may translate the transactionupdate into at least another format. The at least another format may bea generic format that may be suitable for processing and transmitting bythe transaction processor 120 in accordance with the present disclosure.In one embodiment, the reconciliation system may translate thetransaction update into a format suitable for normalization. At step908, the reconciliation system may transmit the transaction update to anotification handler (e.g., payment notification handler 406). At step910, the reconciliation system may receive transaction data associatedwith the transaction update from a transaction query system (e.g., thetransaction query system(s) 408). At step 912, the reconciliation systemmay transmit the transaction update to a transaction requestor (e.g.,requestor system(s) 110) associated with the transaction data. In oneembodiment, the transaction update may be transmitted to the transactionrequestor via an Application Programing Interface (API) call and/or aSecure File Transfer Protocol (SFTP) message. In one embodiment, thereconciliation system may transmit the transaction update to an accountledger system (e.g., account ledger system(s) 306), an auditing system(e.g., auditing system(s) 220), and/or a transaction system (e.g.,transaction system(s) 216) via one or more transaction event-topicstreams. In one embodiment, the real-time transaction system maygenerate one or more interface including information associated with oneor more statuses of the transaction request based on the transactionupdate.

In addition to a standard desktop, or server, it is fully within thescope of this disclosure that any computer system capable of therequired storage and processing demands would be suitable for practicingthe embodiments of the present disclosure. This may include tabletdevices, smart phones, pin pad devices, and any other computer devices,whether mobile or even distributed on a network (i.e., cloud based).

Unless specifically stated otherwise, as apparent from the followingdiscussions, it is appreciated that throughout the specificationdiscussions utilizing terms such as “processing,” “computing,”“calculating,” “determining”, analyzing” or the like, refer to theaction and/or processes of a computer or computing system, or similarelectronic computing device, that manipulate and/or transform datarepresented as physical, such as electronic, quantities into other datasimilarly represented as physical quantities.

In a similar manner, the term “processor” may refer to any device orportion of a device that processes electronic data, e.g., from registersand/or memory to transform that electronic data into other electronicdata that, e.g., may be stored in registers and/or memory. A “computer,”a “computing machine,” a “computing platform,” a “computing device,” ora “server” may include one or more processors.

FIG. 10 illustrates a computer system designated 1000. The computersystem 1000 can include a set of instructions that can be executed tocause the computer system 1000 to perform any one or more of the methodsor computer based functions disclosed herein. The computer system 1000may operate as a standalone device or may be connected, e.g., using anetwork, to other computer systems or peripheral devices.

In a networked deployment, the computer system 1000 may operate in thecapacity of a server or as a client user computer in a server-clientuser network environment, or as a peer computer system in a peer-to-peer(or distributed) network environment. The computer system 1000 can alsobe implemented as or incorporated into various devices, such as apersonal computer (PC), a tablet PC, a set-top box (STB), a personaldigital assistant (PDA), a mobile device, a palmtop computer, a laptopcomputer, a desktop computer, a communications device, a wirelesstelephone, a land-line telephone, a control system, a camera, a scanner,a facsimile machine, a printer, a pager, a personal trusted device, aweb appliance, a network router, switch or bridge, or any other machinecapable of executing a set of instructions (sequential or otherwise)that specify actions to be taken by that machine. In a particularimplementation, the computer system 900 can be implemented usingelectronic devices that provide voice, video, or data communication.Further, while a single computer system 900 is illustrated, the term“system” shall also be taken to include any collection of systems orsub-systems that individually or jointly execute a set, or multiplesets, of instructions to perform one or more computer functions.

As illustrated in FIG. 10 , the computer system 1000 may include aprocessor 1002, e.g., a central processing unit (CPU), a graphicsprocessing unit (GPU), or both. The processor 1002 may be a component ina variety of systems. For example, the processor 1002 may be part of astandard personal computer or a workstation. The processor 1002 may beone or more general processors, digital signal processors, applicationspecific integrated circuits, field programmable gate arrays, servers,networks, digital circuits, analog circuits, combinations thereof, orother now known or later developed devices for analyzing and processingdata. The processor 1002 may implement a software program, such as codegenerated manually (i.e., programmed).

The computer system 1000 may include a memory 1004 that can communicatevia a bus 1008. The memory 1004 may be a main memory, a static memory,or a dynamic memory. The memory 1004 may include, but is not limited tocomputer readable storage media such as various types of volatile andnon-volatile storage media, including but not limited to random accessmemory, read-only memory, programmable read-only memory, electricallyprogrammable read-only memory, electrically erasable read-only memory,flash memory, magnetic tape or disk, optical media and the like. In oneimplementation, the memory 1004 includes a cache or random-access memoryfor the processor 1002. In alternative implementations, the memory 1004is separate from the processor 1002, such as a cache memory of aprocessor, the system memory, or other memory. The memory 1004 may be anexternal storage device or database for storing data. Examples include ahard drive, corn pact disc (“CD”), digital video disc (“DVD”), memorycard, memory stick, floppy disc, universal serial bus (“USB”) memorydevice, or any other device operative to store data. The memory 1004 isoperable to store instructions executable by the processor 1002. Thefunctions, acts or tasks illustrated in the figures or described hereinmay be performed by the programmed processor 1002 executing theinstructions stored in the memory 1004. The functions, acts or tasks areindependent of the particular type of instructions set, storage media,processor or processing strategy and may be performed by software,hardware, integrated circuits, firm-ware, micro-code and the like,operating alone or in combination. Likewise, processing strategies mayinclude multiprocessing, multitasking, parallel payment and the like.

As shown, the computer system 1000 may further include a display unit1010, such as a liquid crystal display (LCD), an organic light emittingdiode (OLED), a flat panel display, a solid-state display, a cathode raytube (CRT), a projector, a printer or other now known or later developeddisplay device for outputting determined information. The display 1010may act as an interface for the user to see the functioning of theprocessor 1002, or specifically as an interface with the software storedin the memory 1004 or in the drive unit 1006.

Additionally or alternatively, the computer system 1000 may include aninput device 1012 configured to allow a user to interact with any of thecomponents of system 1000. The input device 1012 may be a number pad, akeyboard, or a cursor control device, such as a mouse, or a joystick,touch screen display, remote control, or any other device operative tointeract with the computer system 1000.

The computer system 1000 may also or alternatively include a disk oroptical drive unit 1006. The disk drive unit 1006 may include acomputer-readable medium 1022 in which one or more sets of instructions1024, e.g., software, can be embedded. Further, the instructions 1024may embody one or more of the methods or logic as described herein. Theinstructions 1024 may reside completely or partially within the memory1004 and/or within the processor 1002 during execution by the computersystem 1000. The memory 1004 and the processor 1002 also may includecomputer-readable media as discussed above.

In some systems, a computer-readable medium 1022 includes instructions1024 or receives and executes instructions 1024 responsive to apropagated signal so that a device connected to a network 1005 cancommunicate voice, video, audio, images, or any other data over thenetwork 1005. Further, the instructions 1024 may be transmitted orreceived over the network 1005 via a communication port or interface1020, and/or using a bus 1008. The communication port or interface 1020may be a part of the processor 1002 or may be a separate component. Thecommunication port 1020 may be created in software or may be a physicalconnection in hardware. The communication port 1020 may be configured toconnect with a network 1005, external media, the display 1010, or anyother components in system 1000, or combinations thereof. The connectionwith the network 1005 may be a physical connection, such as a wiredEthernet connection or may be established wirelessly as discussed below.Likewise, the additional connections with other components of the system1000 may be physical connections or may be established wirelessly. Thenetwork 1005 may alternatively be directly connected to the bus 1008.

While the computer-readable medium 1022 is shown to be a single medium,the term “computer-readable medium” may include a single medium ormultiple media, such as a centralized or distributed database, and/orassociated caches and servers that store one or more sets ofinstructions. The term “computer-readable medium” may also include anymedium that is capable of storing, encoding, or carrying a set ofinstructions for execution by a processor or that cause a computersystem to perform any one or more of the methods or operations disclosedherein. The computer-readable medium 1022 may be non-transitory, and maybe tangible.

The computer-readable medium 1022 can include a solid-state memory suchas a memory card or other package that houses one or more non-volatileread-only memories. The computer-readable medium 1022 can be arandom-access memory or other volatile re-writable memory. Additionallyor alternatively, the computer-readable medium 1022 can include amagneto-optical or optical medium, such as a disk or tapes or otherstorage device to capture carrier wave signals such as a signalcommunicated over a transmission medium. A digital file attachment to anemail or other self-contained information archive or set of archives maybe considered a distribution medium that is a tangible storage medium.Accordingly, the disclosure is considered to include any one or more ofa computer-readable medium or a distribution medium and otherequivalents and successor media, in which data or instructions may bestored.

In an alternative implementation, dedicated hardware implementations,such as application specific integrated circuits, programmable logicarrays and other hardware devices, can be constructed to implement oneor more of the methods described herein. Applications that may includethe apparatus and systems of various implementations can broadly includea variety of electronic and computer systems. One or moreimplementations described herein may implement functions using two ormore specific interconnected hardware modules or devices with relatedcontrol and data signals that can be communicated between and throughthe modules, or as portions of an application-specific integratedcircuit. Accordingly, the present system encompasses software, firmware,and hardware implementations.

The computer system 1000 may be connected to one or more networks 1005.The network 1005 may define one or more networks including wired orwireless networks. The wireless network may be a cellular telephonenetwork, an 802.11, 802.16, 802.20, or WiMAX network. Further, suchnetworks may include a public network, such as the Internet, a privatenetwork, such as an intranet, or combinations thereof, and may utilize avariety of networking protocols now available or later developedincluding, but not limited to TCP/IP based networking protocols. Thenetwork 1005 may include wide area networks (WAN), such as the Internet,local area networks (LAN), campus area networks, metropolitan areanetworks, a direct connection such as through a Universal Serial Bus(USB) port, or any other networks that may allow for data communication.The network 1005 may be configured to couple one computing device toanother computing device to enable communication of data between thedevices. The network 1005 may generally be enabled to employ any form ofmachine-readable media for communicating information from one device toanother. The network 1005 may include communication methods by whichinformation may travel between computing devices. The network 1005 maybe divided into sub-networks. The sub-networks may allow access to allof the other components connected thereto or the sub-networks mayrestrict access between the components. The network 1005 may be regardedas a public or private network connection and may include, for example,a virtual private network or an encryption or other security mechanismemployed over the public Internet, or the like.

In accordance with various implementations of the present disclosure,the methods described herein may be implemented by software programsexecutable by a computer system. Further, in an exemplary, non-limitedimplementation, implementations can include distributed processing,component/object distributed processing, and parallel payment.Alternatively, virtual computer system processing can be constructed toimplement one or more of the methods or functionality as describedherein.

Although the present specification describes components and functionsthat may be implemented in particular implementations with reference toparticular standards and protocols, the disclosure is not limited tosuch standards and protocols. For example, standards for Internet andother packet switched network transmission (e.g., TCP/IP, UDP/IP, HTML,HTTP, etc.) represent examples of the state of the art. Such standardsare periodically superseded by faster or more efficient equivalentshaving essentially the same functions. Accordingly, replacementstandards and protocols having the same or similar functions as thosedisclosed herein are considered equivalents thereof.

It will be understood that the steps of methods discussed are performedin one embodiment by an appropriate processor (or processors) of aprocessing (i.e., computer) system executing instructions(computer-readable code) stored in storage. It will also be understoodthat the disclosed embodiments are not limited to any particularimplementation or programming technique and that the disclosedembodiments may be implemented using any appropriate techniques forimplementing the functionality described herein. The disclosedembodiments are not limited to any particular programming language oroperating system.

It should be appreciated that in the above description of exemplaryembodiments, various features of the embodiments are sometimes groupedtogether in a single embodiment, figure, or description thereof for thepurpose of streamlining the disclosure and aiding in the understandingof one or more of the various inventive aspects. This method ofdisclosure, however, is not to be interpreted as reflecting an intentionthat a claimed embodiment requires more features than are expresslyrecited in each claim. Rather, as the following claims reflect,inventive aspects lie in less than all features of a single foregoingdisclosed embodiment. Thus, the claims following the DetailedDescription are hereby expressly incorporated into this DetailedDescription, with each claim standing on its own as a separateembodiment.

Furthermore, while some embodiments described herein include some butnot other features included in other embodiments, combinations offeatures of different embodiments are meant to be within the scope ofthe present disclosure, and form different embodiments, as would beunderstood by those skilled in the art. For example, in the followingclaims, any of the claimed embodiments can be used in any combination.

Furthermore, some of the embodiments are described herein as a method orcombination of elements of a method that can be implemented by aprocessor of a computer system or by other means of carrying out thefunction. Thus, a processor with the necessary instructions for carryingout such a method or element of a method forms a means for carrying outthe method or element of a method. Furthermore, an element describedherein of an apparatus embodiment is an example of a means for carryingout the function performed by the element for the purpose of carryingout the function.

In the description provided herein, numerous specific details are setforth. However, it is understood that embodiments of the presentdisclosure may be practiced without these specific details. In otherinstances, well-known methods, structures and techniques have not beenshown in detail in order not to obscure an understanding of thisdescription.

Similarly, it is to be noticed that the term coupled, when used in theclaims, should not be interpreted as being limited to direct connectionsonly. The terms “coupled” and “connected,” along with their derivatives,may be used. It should be understood that these terms are not intendedas synonyms for each other. Thus, the scope of the expression a device Acoupled to a device B should not be limited to devices or systemswherein an output of device A is directly connected to an input ofdevice B. It means that there exists a path between an output of A andan input of B which may be a path including other devices or means.“Coupled” may mean that two or more elements are either in directphysical or electrical contact, or that two or more elements are not indirect contact with each other but yet still co-operate or interact witheach other.

Thus, while there has been described what are believed to be thepreferred embodiments of the present disclosure, those skilled in theart will recognize that other and further modifications may be madethereto without departing from the spirit of the present disclosure, andit is intended to claim all such changes and modifications as fallingwithin the scope of the present disclosure. For example, any formulasgiven above are merely representative of procedures that may be used.Functionality may be added or deleted from the block diagrams andoperations may be interchanged among functional blocks. Steps may beadded or deleted to methods described within the scope of the presentdisclosure.

The above disclosed subject matter is to be considered illustrative, andnot restrictive, and the appended claims are intended to cover all suchmodifications, enhancements, and other implementations, which fallwithin the true spirit and scope of the present disclosure. Thus, to themaximum extent allowed by law, the scope of the present disclosure is tobe determined by the broadest permissible interpretation of thefollowing claims and their equivalents, and shall not be restricted orlimited by the foregoing detailed description. While variousimplementations of the disclosure have been described, it will beapparent to those of ordinary skill in the art that many moreimplementations and implementations are possible within the scope of thedisclosure. Accordingly, the disclosure is not to be restricted exceptin light of the attached claims and their equivalents.

What is claimed is:
 1. A method of routing a transaction using areal-time transaction system, the method comprising: receiving, at arouting system associated with the real-time transaction system, atransaction request made by a user; identifying, using the routingsystem, user preferences associated with the transaction request andcharacteristics associated with one or more transaction schemes;determining, based on the identifying and using a routing decision modelof the routing system, an optimal route for the transaction request; andprocessing, using the routing system, the transaction request via thedetermined optimal route.
 2. The method of claim 1, wherein thecharacteristics associated with the one or more transaction schemesinclude at least one of: scheme execution dates, scheme decisions,scheme holidays, scheme processing time, scheme costs, and scheme amountlimits.
 3. The method of claim 1, wherein the user preferences include adesired transaction date.
 4. The method of claim 1, wherein thedetermining comprises comparing price, speed, and capability metricsindicated in the user preferences with the price, the speed, and thecapability metrics associated with the one or more transaction schemes.5. The method of claim 1, wherein the determining comprises determiningthe optimal route based on further identifying whether the transactionrequest is a domestic transaction or a cross-border transaction.
 6. Themethod of claim 1, further comprising: receiving, from a fraudmonitoring system associated with the routing system, feedback based ona fraud profiling process conducted for the transaction request; andadjusting the determination of the optimal route based on the feedback.7. The method of claim 1, further comprising: receiving, from a trainedmachine learning model associated with the routing system, feedbackbased on identified transaction trends; and adjusting the determinationof the optimal route based on the feedback.
 8. A real-time transactionsystem comprising: one or more computer readable media storinginstructions for executing a real-time electronic transaction; and oneor more processors configured to execute the instructions to performoperations comprising: receiving, at a routing system associated withthe real-time transaction system, a transaction request made by a user;identifying, using the routing system, user preferences associated withthe transaction request and characteristics associated with one or moretransaction schemes; determining, based on the identifying and using arouting decision model of the routing system, an optimal route for thetransaction request; and processing, using the routing system, thetransaction request via the determined optimal route.
 9. The real-timetransaction system of claim 8, wherein the characteristics associatedwith the one or more transaction schemes include at least one of: schemeexecution dates, scheme decisions, scheme holidays, scheme processingtime, scheme costs, and scheme amount limits.
 10. The real-timetransaction system of claim 8, wherein the user preferences include adesired transaction date.
 11. The real-time transaction system of claim8, wherein the determining comprises comparing price, speed, andcapability metrics indicated in the user preferences with the price, thespeed, and the capability metrics associated with the one or moretransaction schemes.
 12. The real-time transaction system of claim 8,wherein the determining comprises determining the optimal route based onfurther identifying whether the transaction request is a domestictransaction or a cross-border transaction.
 13. The real-time transactionsystem of claim 8, further comprising: receiving, from a fraudmonitoring system associated with the routing system, feedback based ona fraud profiling process conducted for the transaction request; andadjusting the determination of the optimal route based on the feedback.14. The real-time transaction system of claim 8, further comprising:receiving, from a trained machine learning model associated with therouting system, feedback based on identified transaction trends; andadjusting the determination of the optimal route based on the feedback.15. A non-transitory computer-readable medium storing instructions forexecuting a real-time transaction, the instructions, when executed byone or more processors, causing the one or more processors to performoperations comprising: receiving, at a routing system associated withthe real-time transaction system, a transaction request made by a user;identifying, using the routing system, user preferences associated withthe transaction request and characteristics associated with one or moretransaction schemes; determining, based on the identifying and using arouting decision model of the routing system, an optimal route for thetransaction request; and processing, using the routing system, thetransaction request via the determined optimal route.
 16. Thenon-transitory computer-readable medium of claim 15, wherein thecharacteristics associated with the one or more transaction schemesinclude at least one of: scheme execution dates, scheme decisions,scheme holidays, scheme processing time, scheme costs, and scheme amountlimits.
 17. The non-transitory computer-readable medium of claim 15,wherein the determining comprises comparing price, speed, and capabilitymetrics indicated in the user preferences with the price, the speed, andthe capability metrics associated with the one or more transactionschemes.
 18. The non-transitory computer-readable medium of claim 15,wherein the determining comprises determining the optimal route based onfurther identifying whether the transaction request is a domestictransaction or a cross-border transaction.
 19. The non-transitorycomputer-readable medium of claim 15, further comprising: receiving,from a fraud monitoring system associated with the routing system,feedback based on a fraud profiling process conducted for thetransaction request; and adjusting the determination of the optimalroute based on the feedback.
 20. The non-transitory computer-readablemedium of claim 15, further comprising: receiving, from a trainedmachine learning model associated with the routing system, feedbackbased on identified transaction trends; and adjusting the determinationof the optimal route based on the feedback.